I submitted a report on this via Feedback Assistant yesterday. It got closed fairly fast: Recent Similar Reports: Less than 10 Resolution: Investigation Complete - Works as currently designed Very frustrating. But maybe it would help if everyone affected could submit their own feedback ticket and bump up that "recent similar reports" count until someone at Apple decides to take a second look.

Here's what I submitted via Feedback Assistant: Title: mailto URL scheme no longer supports line breaks Area: Mail Type: Incorrect/Unexpected Behavior Mail 14.6 no longer supports mailto URLs containing the “%0D%0A” character sequence to specify a line break in the message body. Instead of a line break, this sequence gets converted to literal text “<BR>” in the message body. For apps that use specific formatting in mailto-generated messages to drive back-end business logic, this is a disastrous regression. This bug is in the Apple Mail app, not in the OS handling of mailto URLs. If you change your default mail app to (for example) Outlook or Gmail, then the “%0D%0A” sequence is still handled correctly. This affects a lot of apps. Please see this Apple Developer Forum thread for discussion of the impact: https://developer.apple.com/forums/thread/681023 In that forum thread, note the response from “Frameworks Engineer ” who seems to fundamentally misunderstand the issue. Please ensure that this issue is understood as breakage of previously correct behavior. “Support for rich content…has been removed” does not explain the new behavior that inserts the unexpected text “<BR>” into the specified message.

Actually that version of Xcode should support devices running 14.6 or 14.7 just fine. When you first plug in a device with an unknown OS, then Xcode downloads from it the debugger symbol files it needs, and then deploying and running should Just Work™. If this isn't working, plug in and check the Devices and Simulators window for any error messages. The symbol files get placed under ~/Library/Developer/Xcode/iOS Support/. It’s safe to clean out that iOS Support directory, as the bundles for your current devices will grow back as needed when you plug them in.

There's no equivalent functionality on iOS for this. In the screenshot, WhatsApp presumably uses custom logic to check for specific popular map apps that it knows about, using their public URL schemes, and then it presents them in a simple action sheet. Some other apps do the same. There's no publicly documented OS support for "get a list of all installed map apps that I can launch from my app" or "present a view controller with a list of all installed map apps" which would be analogous to what you can do on Android.

The error message is accurate. In your example data, the token NULL is not valid JSON. It’s case-sensitive so it needs to be spelled as null.

They may be complaining that your app resembles a certain book (available on Apple Books) rather than any app. You may need to prove that your app is in fact affiliated with that book and not an unauthorized ripoff. (As to why this comes up in review of a minor update rather than the first time you submitted the app... it’s best to just not give yourself headaches trying to guess how App Review does these things.)

Your example JSON response shows a single object, but the decoder is expecting an array of objects.

It’s the extern "C" declaration. That's a C++ language feature, but the bridging header needs to be pure C (or Objective-C). If that code is in an external or shared header file then you can wrap it in an #ifdef __cplusplus guard. Or if it's directly in your bridging header in the project, you can just remove it.

The screenshot seems to have disappeared from your post, but I saw it earlier and noticed that your project path contains spaces and commas. Not necessarily your problem here but it’s worth looking into. You need to be careful about that when writing custom build phase scripts, using 3rd party tools that have their own scripting, etc. (I find it easiest to just avoid using paths with spaces or other characters that can cause scripting headaches.)

Short answer: There is no native Windows version of Xcode. Longer answer: Depending on what you want to learn or accomplish, a quick Goog Bing search will turn up some interesting workarounds that may be useful in certain circumstances. However, if you're at all serious about app development for Apple platforms, there's no realistic alternative to just getting a Mac.

You want to discover battery usage of details about other apps that the user has installed on their device? That's almost certainly never going to be supported, as it’s a massive privacy fail.

There isn't currently a simulator for 14.7.1, and generally there isn't a simulator for every OS release. Expect to see simulator releases that correspond to meaningful API changes but not for security patches or other user-facing feature fixes. So the simulator can never fully substitute for testing on a real device.

Sorry, no. You may have seen apps that do this on Android, but on iOS there is no such capability.

I expected the sequence to be returned in order, from 0 to 9. This expectation is based only on the previous observed behavior, not on the documented behavior, so it turned out not to be a safe expectation. The issue is that there is no documented relationship between (1) the value returned from your RNG's next() method; and (2) the result of calling Array.randomElement(using:) or Int.random(in:using:). That is, exactly how those methods "use" your RNG is undocumented, and is therefore subject to change. Sounds like randomElement() formerly used your RNG's result directly as the index for the random element, but now it does something different. Both those behaviors are valid as they fulfill the documented API contract. (The documentation for randomElement() actually includes a note that emphasizes this undocumented-ness.) What do I need to do in the random number generator implementation to get it to work with arrays (and ranges) correctly? The current behavior is "correct", so let's change the question to: What do I need to do in the RNG implementation to achieve specific desired behavior in Array.randomElement(using:) both now and in future versions of the Swift library? The answer is: you can't. However, you may be able to achieve your testing goals by using your RNG in a different way, such as using it to generate pseudo-random array indexes directly, to replace usage of the system's randomElement() method. Or maybe you just want to iterate directly over the collection and perform testing logic on each element. It just depends on what you're trying to do.

Nobody can "fix" this without seeing the actual code that has the error, so please post that. Remember to use the "code block" formatting feature in the editor, and cut down the code sample to the bare minimum that still demonstrates the issue. But first, consider the error message: the compiler says you are trying to divide two operands which aren't actually numbers, but which are actually each a function or closure. Why is that? Are you intending to divide two numbers? If so, why does the compiler think they aren't numbers? Work backward from the point of the error to see how each operand is defined.